# 데이터베이스 쿼리 캐시

## 개요

**데이터베이스 쿼리 캐시**(Query Cache)는 동일한 SQL 쿼리가 반복적으로 실행될 때, 이전 실행 결과를 메모리에 저장하여 다음 실행 시 빠르게 응답할 수 있도록 하는 최적화 기법이다. 쿼리 캐시는 데이터베이스 서버의 성능을 크게 향상시킬 수 있으며, 특히 읽기 중심(read-heavy) 워크로드에서 효과적이다. 그러나 데이터가 자주 변경되는 환경에서는 캐시 무효화 비용이 커질 수 있어 주의가 필요하다.

이 문서는 쿼리 캐시의 작동 원리, 장단점, 주요 데이터베이스 시스템에서의 지원 현황, 그리고 실무에서의 활용 전략에 대해 설명한다.

---

## 작동 원리

### 1. 쿼리 해시 기반 저장

쿼리 캐시는 일반적으로 SQL 문 전체를 **해시 값**(Hash)으로 변환하여 키로 사용한다. 동일한 쿼리가 들어오면 이 해시를 조회해 캐시에 결과가 존재하는지 확인한다.

예를 들어, 다음과 같은 쿼리가 있다고 하자:

```sql
SELECT name, email FROM users WHERE id = 100;
```

데이터베이스는 이 쿼리를 해싱한 후, 캐시 저장소에서 해당 해시에 매핑된 결과 집합이 있는지 확인한다. 존재하면 디스크 I/O나 인덱스 탐색 없이 메모리에서 바로 결과를 반환한다.

### 2. 캐시 무효화

쿼리 캐시의 가장 중요한 과제 중 하나는 **데이터 일관성** 유지이다. 만약 캐시된 쿼리와 관련된 테이블에 **INSERT**, **UPDATE**, **DELETE** 같은 DML(Data Manipulation Language) 문이 실행되면, 관련된 모든 캐시 항목은 즉시 무효화(invalidate)된다.

예를 들어, `users` 테이블이 변경되면, `SELECT * FROM users`와 같은 쿼리의 캐시는 폐기되어야 한다.

---

## 주요 데이터베이스 시스템에서의 지원

### MySQL

MySQL은 4.0 버전부터 쿼리 캐시를 지원했으며, 5.7까지 기본 활성화 상태였다. 그러나 **MySQL 8.0에서는 쿼리 캐시 기능이 완전히 제거**되었다.

- **이유**: 락 경합(lock contention) 문제, 높은 동시성 환경에서의 성능 저하, 관리 오버헤드 등
- **대안**: 애플리케이션 레벨 캐시(예: Redis, Memcached), 인덱스 최적화, 쿼리 리라이팅

### PostgreSQL

PostgreSQL은 **내장된 전역 쿼리 캐시를 제공하지 않는다**. 그러나 다음과 같은 방식으로 유사한 효과를 낼 수 있다:

- **PL/pgSQL 함수 내부 캐싱**
- **세션 레벨 캐시**(예: prepared statements)
- 외부 캐시 시스템 연동

### SQL Server

Microsoft SQL Server는 **쿼리 캐시**(또는 **실행 계획 캐시**)를 제공하지만, 이는 **실행 계획**(execution plan)을 캐싱하는 것이지, 결과를 캐싱하는 것은 아니다.

- **장점**: 동일한 쿼리의 파싱 및 최적화 비용 절감
- **결과 캐싱**: 필요 시 애플리케이션 레벨 또는 In-Memory OLTP 기능 활용

---

## 장점과 단점

### 장점

| 항목 | 설명 |
|------|------|
| **성능 향상** | 반복 쿼리에 대해 빠른 응답 가능 |
| **리소스 절약** | CPU, 디스크 I/O 사용량 감소 |
| **단순한 구현** | 데이터베이스 내장 기능으로 별도 설정 없이 사용 가능 (지원 시) |

### 단점

| 항목 | 설명 |
|------|------|
| **캐시 무효화 오버헤드** | 데이터 변경 시 관련 캐시 전체 제거 필요 |
| **메모리 사용량 증가** | 대용량 결과 저장 시 메모리 압박 |
| **동시성 문제** | 높은 동시성 환경에서 락 경합 발생 가능 |
| **비효율적 사용** | 고유한 쿼리(예: `WHERE id = ?` 매개변수 변경)는 캐시 효율 낮음 |

---

## 실무 활용 전략

### 1. 애플리케이션 레벨 캐시 사용 권장

내장 쿼리 캐시보다는 **Redis**, **Memcached**와 같은 외부 캐시 시스템을 사용하는 것이 더 유연하고 안정적이다.

```python
# 예시: Redis를 이용한 쿼리 결과 캐싱
import redis
import json

r = redis.Redis()

def get_user(user_id):
    cache_key = f"user:{user_id}"
    cached = r.get(cache_key)
    if cached:
        return json.loads(cached)
    
    # DB 조회
    user = db.query("SELECT * FROM users WHERE id = %s", user_id)
    r.setex(cache_key, 3600, json.dumps(user))  # 1시간 저장
    return user
```

### 2. 캐시 키 설계

- 쿼리 텍스트 외에 **데이터베이스 스키마 버전**, **파라미터 값** 등을 포함해 정확한 캐시 키 생성
- TTL(Time-To-Live) 설정으로 자동 만료 처리

### 3. 읽기 전용 데이터에 집중

- 코드 테이블, 설정 정보, 정적 데이터 등 자주 읽히고 거의 변경되지 않는 데이터에 캐시 적용

---

## 참고 자료

- [MySQL 8.0 Reference Manual - Query Cache](https://dev.mysql.com/doc/refman/8.0/en/query-cache.html)  
- [PostgreSQL Documentation - Query Planning](https://www.postgresql.org/docs/current/runtime-config-query.html)  
- [Microsoft Docs - SQL Server Plan Caching](https://learn.microsoft.com/en-us/sql/relational-databases/query-processing-architecture-guide)  
- Oracle Database Performance Tuning Guide (캐시 및 메모리 관리)

---

## 관련 문서

- [인덱스 최적화](/wiki/database/index-optimization)
- [실행 계획 분석](/wiki/database/query-execution-plan)
- [Redis 캐시 전략](/wiki/technology/redis-caching)

> **참고**: 데이터베이스 쿼리 캐시는 특정 환경에서 유용할 수 있으나, 현대 아키텍처에서는 애플리케이션 레벨 캐시와 함께 더 정교한 최적화 전략을 사용하는 것이 일반적이다.